详谈到底什么是游戏运营三张表
然后呢，虽然之前也写过游戏运营三张表具体是什么，但是确实写的比较枯燥和随意，所以，这一篇，列出游戏运营三张表我常备的固定格式（在下面详细列出），同时也认真解读下为何我对这运营三张表念念不忘……
从我自己构筑的运营方法论来讲，游戏好玩不好玩是玄学，但是目标确定后，运营可以做哪些事情是正经的科学，那么从大的方向上，所有运营的目标，就永远是建立在以下这三个问题的答案之上再去求解：
1、我们期望用户每天上来玩什么？
2、我们期望不同分类（通常是付费）的用户每个版本的极限是什么状态？
3、在2的答案里，我们期望同类用户的消耗是怎么分布？
如你所见，作为运营要回答好这三个问题，单纯用玩家的身份去体验游戏，时间上通常是来不及。所以才需要文档，表格，沟通，然后尽快达成共识，这个情况下，请先理解野路子的一个经验——推进这个表的过程，是有助于尽快判断运营和研发该如何达成某种共识。
因为我所谓的这运营三张表，需要的内容并不独特，是任何正常的研发团队，必然存在于策划文档甚至立项说明里，只是需要耗费时间重新梳理，这个梳理的目的嘛……
一方面，是把产品的散落在策划文档里的，运营业务最关心最需要的部分提炼出来。一方面这个过程里，用属于自己的运营逻辑，去做一次统一定义，达成关于用户行为预期的共识——这样的共识达成了，那么接下来的修改配合，至少业务层面上，基础的定义是运营发起并且跟进达成的，那么沟通和解释的主动权，一定程度自然也在我们运营这边了。
当然，我作为运营负责人，接受新项目时候，和研发对口的策划一起来做这个事情，还有一个重点，那就是在这个构建三张表的过程里，去判断对方合作的态度，能力，以及大家是不是都是做事的人。
说到底，我这些东西是自有一套基于经验和数据积累的逻辑在那里。都是做事的人，那么其实一起推进这个事情，是比较容易建立起初步的信任关系。所以单纯把这些表格拿去让策划填 ，而运营自己不一起参与，大部分情况下策划要么不干，要么就瞎几把乱填了。
具体到运营三张表本身呢，【系统总览表】【开发节奏表】【核心系统付费测算】这三张表的存在价值，其实是拿到手后，推出一个【用户行为预期】的综合汇总，而得到【用户行为预期】汇总，才可能更明确的考虑上述的3个问题的答案是什么，而那3个问题得到了答案后（哪怕最后看可能是错的），接下来就是基于这些答案的预期，预判可行不可行后其他的行为处理，然后才去使用各种成熟的工具，方法，手段，满足现实里公司对产品的期望和达成运营人员个人的小目标 。
所以这里的递进关系就是
运营三张表---->用户行为预期--->三个问题的答案——>各种运营方法论达成目标
只不过呢，推演用户行为预期的汇总，真的需要具体产品具体分析，大胆假设小心求证，而运营三张表属于万用起手，没有研发配合自己也能凑合做出来，然后再去毛估出需要的【用户行为预期】，
运营三张表的格式解读
1、系统总览表：
为什么要？
做运营的固然是需要去熟悉游戏，但是不管游戏还是半成品状态或者游戏已经上线但是运营人员刚刚接手，是非常常见的情况，这个时候就需要通过研发或者自己设定这样性质的表，对要负责的游戏大概是什么，自己具备一个实际体验加策划文档理解的整体概念。
要什么？
1）、列出这游戏当前计划版本和下一个版本的全部系统并且按【自定义的逻辑】进行分类。
所以，这一步，可以这样列
也可以这样列
甚至这样画一个脑图给你也不是不可以（只是脑图需要提供源文件，而不是只给你一张图，顺便也不用费心放大下面这个图，下面单纯就是当年傲视天地的反拆图，而且只有这么一个模糊的图）
2）、按如下格式列出战力提升相关的系统总览——这部分是我需要的系统总览表里，最核心的点，也是必须研发配合才能精确估算的玩意
这个战力相关系统总表起什么用呢？通常正确的给出来后，运营不需要那么精心去玩游戏，也能迅速定位出一些问题，比如我上面这个表里的数据来说，如果没有什么额外的设计，宝物一定是卖的最好或者用户最想要的战力，提升占比高，消耗资源费用最低，每1点战力的提升，花在宝石上，只需要消耗约1钻石，而且在总战力的占比最高，而转生一定是卖的最差或者是高奢的炫耀性设计，因为同样1点战力提升，他需要消耗14钻石，并且在总战力的加成里，只占据了可怜的2.63%，而装备和技能，可能会是一个失败设计——当然，实际情况是不是这样，就要结合游戏和上面的系统总览（里面不是有要求列日常产出）一起分析。
你看，如果和策划一起，认真的填了这个部分，很多问题，在填写好的这一步，就能有一个大概的思考方向了
2、系统开发节奏表：
为什么要？
在系统总览表的基础上，和研发沟通，知晓目前各个系统的开放节奏，这个表完成的基础上，才有可能根据自己的经验和历史数据，还有目标，具备出一个谈调整或者不调整的可能。
要什么？
1）主要是两个部分，当前版本的和未来版本，我是有个固定格式，你可以按你的需要自己设计
2）总表能顺利给出来，这个表一般也跟着就出来，但是这一步经常出的情况呢，是研发经常就丢一个他们自己的版本计划，而项目实际进度和版本计划并不匹配，很容易和线上实际跑出的体验不符，当然，到这一步，这两张表给的过程里，其实也能方便的看出，研发对运营的配合，是一个什么状态，根据对方的配合状态，自己的权责情况，已经可以做一个业务层面，大家是不是一门心思做业务的判断了，那么肯一起做业务，是做业务的解决方法，大不了自己累点，申请下对方策划文档的只读权限，多读读更新列表，多实际跑跑游戏，以业余QA的立场，一个系统一个系统的去一起过，但是对方如果不是一门心思做业务，那么要付出多少，要不要这样或者那样做，就是业务层面之外，运营负责人自己单独考量的事情了。
3、核心系统付费测算表
为什么要？
这个就是在前两个表的基础上，进一步的对商业化的部分进行测算，之前做总表的时候不就已经做了极限战力的系统分配总览吗？那么到这里，其实就是分再去假定免费用户和付费用户能达到的极限值,以及相同条件下，不同付费系统的战力提升性价比（例如，X级情况下不同系统花费1元后可买的战斗力），这个表成型后，才能说是通过文档阶段，具备对游戏的基本了解和梳理，这样才能就如何相对有效的调整付费有共同的讨论基础。
要什么？
这个表真的就没什么固定格式了，因为到这一步，涉及的是具体游戏情况的具体测算，基本上是数值策划去按他方便的逻辑来提供，只不过，能顺利到这一步的，你可以按游戏的实际情况出一个汇总表格，方便自己做全局的通栏，以及为之后的用户行为预期的沟通，提前做好准备。
比如类似这样
或者这样
然后才是针对核心付费系统，按自己方便的格式，一一列出明细和测算，比如我这里常见的是这样
但是再到更具体哪些是反馈游戏进度，强度的标志信息，重点商业化系统的测算和对应的数值关系，这个就需要按自己对游戏理解，拿着前面两张表和策划一起去罗列，一百种产品，到这一步，真的就是有一千种可能了。
——我是分割线——
谢谢大家看到底！如果看完我的杂谈文字野路子经验，你也有感触，欢迎点在看、关注、分享或者给点个「赞」哟